The appendices attached to the disclosure of this patent contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention relates generally to graphical user interfaces (GUIs), i.e. user interfaces in which information can be presented in both textual form and graphical form. More particularly, the invention relates to GUIs used to control, manage, configure, monitor and diagnose software and hardware applications, devices and equipment using a World-Wide-Web client/server communications model. Yet more particularly, the invention relates to methods and apparatus for developing and using such GUIs based on a World-Wide-Web client/server communications model.
2. Related Art
Many modern communications, entertainment and other electronic devices require or could benefit from improved local or remote control, management, configuration, monitoring and diagnosing. It is common for such devices to be controlled by a software application program specifically written for each device. The design of such a device includes any hardware and operating environment software needed to support the application, which is then referred to as an embedded application, because it is embedded within the device. Embedded application programs are generally written in a high-level programming language such as C, C++, etc., referred to herein as a native application programming language. Other languages suitable to particular uses may also be employed. The application program communicates with users through a user interface, generally written in the same high-level language as the application.
The representation of an application in a native application programming language is referred to as the application program source code. A corresponding representation, which can be executed on a processor, is referred to as an executable image.
Before an application written in a high-level language can be executed it must be compiled and linked to transform the application source code into an executable image. A compiler receives as an input a file containing the application source code and produces as an output a file in a format referred to as object code. Finally, one or more object code files are linked to form the executable image. Linking resolves references an object module may make outside of that object module, such as addresses, symbols or functions defined elsewhere.
Source code may also define arrangements by which data can be stored in memory and conveniently referred to symbolically. Such defined arrangements are referred to as data structures because they represent the physical arrangement of data within memory, i.e., the structure into which the data is organized.
Most commonly, remote control, management, configuration, monitoring and diagnosing applications employ unique proprietary user interfaces integrated with the application software and embedded into the device. Frequently these user interfaces present and receive information in text form only. Moreover, they are not portable, generally being designed to operate on a specific platform, i.e., combination of hardware and software. The devices for which control, management, configuration and diagnosing are desired have only limited run-time resources available, such as memory and long-term storage space. Proprietary interfaces are frequently designed with such limitations to data presentation, data acquisition and portability because of the development costs incurred in providing such features and in order to keep the size and run-time resource requirements of the user interface to a minimum. Since each user interface tends to be unique to the particular remote control, management, configuration, monitoring or diagnosing function desired, as well as unique to the operating system, application and hardware platform upon which these operations are performed, significant time and/or other resources may be expended in development. Graphics handling and portability have therefore been considered luxuries too expensive for most applications.
However, as the range of products available requiring control, management, configuration, monitoring or diagnosing increase, such former luxuries as graphical presentation and portability of the interface from platform to platform have migrated from the category of luxuries to that of necessities. It is well known that information presented graphically is more quickly and easily assimilated than the same information presented as text. It is also well known that a consistent user interface presented by a variety of platforms is more likely to be understood and properly used than unique proprietary user interfaces presented by each individual platform. Therefore, portable GUIs with low ran-time resource requirements are highly desirable.
With the growing popularity and expansion of the Internet, one extremely popular public network for communications between computer systems, and development of the World-Wide-Web communication and presentation model, a new paradigm for communication of information has emerged.
The World-Wide-Web and similar private architectures such as internal corporate LANs, provide a xe2x80x9cwebxe2x80x9d of interconnected document objects. On the World-Wide-Web, these document objects are located on various sites on the global Internet. The World-Wide-Web is also described in xe2x80x9cThe World-Wide Web,xe2x80x9d by T. Berners-Lee, R. Cailliau, A. Luotonen, H. F. Nielsen, and A. Secret, Communications of the ACM, 37 (8), pp. 76-82, August 1994, and in xe2x80x9cWorld Wide Web: The Information Universe,xe2x80x9d by Berners-Lee, T., et al., in Electronic Networking: Research, Applications and Policy, Vol. 1, No. 2, Meckler, Westport, Conn., Spring 1992. On the Internet, the World-Wide-Web is a collection of documents (i.e., content), client software (i.e., browsers) and server software (i.e., servers) which cooperate to present and receive information from users. The World-Wide-Web is also used to connect users through the content to a variety of databases and services from which information may be obtained. However, except as explained below, the World-Wide-Web is based principally on static information contained in the content documents available to the browsers through the servers. Such a limitation would make the World-Wide-Web paradigm useless as a GUI, which must present dynamic information generated by a device or application.
The World-Wide-Web communications paradigm is based on a conventional client-server model. Content is held in documents accessible to servers. Clients can request, through an interconnect system, documents which are then served to the clients through the interconnect system. The client software is responsible for interpreting the contents of the document served, if necessary.
Among the types of document objects in a xe2x80x9cwebxe2x80x9d are documents and scripts. Documents in the World-Wide-Web may contain text, images, video, sound or other information sought to be presented, in undetermined formats known to browsers or extensions used with browsers. The presentation obtained or other actions performed when a browser requests a document from a server is usually determined by text contained in a document which is written in Hypertext Mark-up Language (HTML). HTML is described in HyperText Markup Language Specificationxe2x80x942.0, by T. Berners-Lee and D. Connolly, RFC 1866, proposed standard, November 1995, and in xe2x80x9cWorld Wide Web and HTML,xe2x80x9d by Douglas C. McArthur, in Dr. Dobbs Journal, December 1994, pp. 18-20, 22, 24, 26 and 86. HTML documents stored as such are generally static, that is, the contents do not change over time except when the document is manually modified. Scripts are programs that can generate HTML documents when executed.
HTML is one of a family of computer languages referred to as mark-up languages. Mark-up languages are computer languages, which describe how to display, print, etc. a text document in a device-independent way. The description takes the form of textual tags indicating a format to be applied or other action to be taken relative to document text. The tags are usually unique character strings having defined meanings in the mark-up language. Tags are described in greater detail, below.
HTML is used in the World-Wide-Web because it is designed for writing hypertext documents. The formal definition is that HTML documents are Standard Generalized Markup Language (SGML) documents that conform to a particular Document Type Definition (DTD). An HTML document includes a hierarchical set of markup elements, where most elements have a start tag, followed by content, followed by an end tag. The content is a combination of text and nested markup elements. Tags are enclosed in angle brackets (xe2x80x98 less than xe2x80x99 and xe2x80x98 greater than xe2x80x99) and indicate how the document is structured and how to display the document, as well as destinations and labels for hypertext links. There are tags for markup elements such as titles, headers, text attributes such as bold and italic, lists, paragraph boundaries, links to other documents or other parts of the same document, in-line graphic images, and many other features.
For example, here are several lines of HTML:
Some words are  less than B greater than bold less than /B greater than , others are  less than I greater than italic less than /I greater than . Here we start a new paragraph. less than P greater than Here""s a link to the  less than A HREF=xe2x80x9chttp://www.agranat.comxe2x80x9d greater than Agranat Systems, Inc. less than /A greater than home page.
This sample document is a hypertext document because it contains a xe2x80x9clinkxe2x80x9d to another document, as provided by the xe2x80x9cHREF=.xe2x80x9d The format of this link will be described below. A hypertext document may also have a link to other parts of the same document. Linked documents may generally be located anywhere on the Internet. When a user is viewing the document using a client program called a Web browser (described below), the links are displayed as highlighted words or phrases. For example, using a Web browser, the sample document above would be displayed on the user""s screen as follows:
Some words are bold, others are italic. Here we start a new paragraph.
Here""s a link to Agranat Systems, Inc. home page.
In the Web browser, the link may be selected, for example by clicking on the highlighted area with a mouse. Selecting a link will cause the associated document to be displayed. Thus, clicking on the highlighted text xe2x80x9cAgranat Systems, Inc.xe2x80x9d would display that home page.
Although a browser can be used to directly request images, video, sound, etc. from a server, more usually an HTML document which controls the presentation of information served to the browser by the server is requested. However, except as noted below, the contents of an HTML file are static, i.e., the browser can only present a passive snapshot of the contents at the time the document is served. In order to present dynamic information, i.e., generated by an application or device, or obtain from the user data which has been inserted into an HTML-generated form, conventional World-Wide-Web servers use a xe2x80x9crawxe2x80x9d interface, such as the common gateway interface (CGI), explained below. HTML provides no mechanism for presenting dynamic information generated by an application or device, except through a raw interface, such as the CGI. Regarding obtaining data from the user for use by the application or device, although standard HTML provides a set of tags which implement a convenient mechanism for serving interactive forms to the browser, complete with text fields, check boxes and pull-down menus, the CGI must be used to process submitted forms. Form processing is important to remote control, management, configuration, monitoring and diagnosing applications because forms processing are a convenient way to configure an application according to user input using the World-Wide-Web communications model. But, form processing using a CGI is extremely complex, as will be seen below, requiring an application designer to learn and implement an unfamiliar interface. A CGI is therefore not a suitable interface for rapid development and prototyping of new GUI capabilities. Moreover, a developer must then master a native application source code language (e.g., C, C++, etc.), HTML and the CGI, in order to develop a complete application along with its user interface.
Models of the World-Wide-Web communications paradigm for static content and dynamic content are shown in FIGS. 14 and 15, respectively. As shown in FIG. 14, a browser 1401 makes a connection 1402 with a server 1403, which serves static content 1405 from a storage device 1407 to the browser 1401. In the case of dynamic content, shown in FIG. 15, the server 1403 passes control of the connection 1402 with the browser 1401 to an application 1501, through the CGI 1503. The application 1501 must maintain the connection 1402 with the browser 1401 and must pass control back to the server 1403 when service of the request, which included dynamic content, is complete. Furthermore, during service of a request which includes dynamic content, the application 1501 is responsible for functions normally performed by the server 1403, including maintaining the connection 1402 with the browser 1401, generating headers in the server/browser transport protocol, generating all of the static and dynamic content elements, and parsing any form data returned by the user. Since use of the CGI 1503 or other raw interface forces the application designer to do all of this work, applications 1501 to which forms are submitted are necessarily complex.
In order to provide dynamic content to a browser, the World-Wide-Web has also evolved to include Java and other client side scripting languages, as well as some server side scripting languages. However, these languages are interpreted by an interpreter built into the browser 1401 or server 1403, slowing down the presentation of information so generated. In the case of client side scripting, the script does not have any direct access to the application or to application specific information. Therefore, in order to generate or receive application specific information using client side scripting, the CGI 1503 or other raw interface must still be used. In the case of server side scripting, the server 1403 must parse the content as it is served, looking for a script to be interpreted. The access, which a script has to the application, is limited by the definition of the scripting language, rather than by an application software interface designed by the application designer.
A server side script is an executable program, or a set of commands stored in a file, that can be run by a server program to produce an HTML document that is then returned to the Web browser. Typical script actions include running library routines or other applications to get information from a file, a database or a device, or initiating a request to get information from another machine, or retrieving a document corresponding to a selected hypertext link. A script may be run on the Web server when, for example, the end user selects a particular hypertext link in the Web browser, or submits an HTML form request. Scripts are usually written in an interpreted language such as Basic, Practical Extraction and Report Language (Perl) or Tool Control Language (Tcl) or one of the Unix operating system shell languages, but they also may be written in programming languages such as the xe2x80x9cCxe2x80x9d programming language and then compiled into an executable program. Programming in Tcl is described in more detail in Tcl and the Tk Toolkit, by John K. Ousterhout, Addison-Wesley, Reading, Mass., USA, 1994. Perl is described in more detail in Programming Perl, by Larry Wall and Randal L. Schwartz, O""Reilly and Associates, Inc., Sebastopol, Calif., USA, 1992.
Each document object in a web has an identifier called a Universal Resource Identifier (URI). These identifiers are described in more detail in T. Berners-Lee, xe2x80x9cUniversal Resource Identifiers in World-Wide-Web: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web,xe2x80x9d RFC 1630, CERN, June 1994; and T. Berners-Lee, L. Masinter, and M. McCahill, xe2x80x9cUniform Resource Locators (URL),xe2x80x9d RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. A URI allows any object on the Internet to be referred to by name or address, such as in a link in an HTML document as shown above. There are two types of URIs: a Universal Resource Name (URN) and a Uniform Resource Locator (URL). A URN references an object by name within a given name space. The Internet community has not yet fully defined the syntax and usage of URNs. A URL references an object by defining an access algorithm using network protocols. An example URL is xe2x80x9chttp://www.agranat.comxe2x80x9d A URL has the syntax xe2x80x9cscheme: scheme_specific_componentsxe2x80x9d where
a xe2x80x9cschemexe2x80x9d identifies the access protocol (such as HTTP, FTP or GOPHER).
For a scheme of HTTP, the URL may be of the form xe2x80x9chttp://host:port/path?searchxe2x80x9d where
xe2x80x9chostxe2x80x9d is the Internet domain name of the machine that supports the protocol;
xe2x80x9cportxe2x80x9d is the transmission control protocol (TCP) port number of the appropriate server (if different from the default);
xe2x80x9cpathxe2x80x9d is a scheme-specific identification of the object; and
xe2x80x9csearchxe2x80x9d contains optional parameters for querying the content of the object.
URLs are also used by web servers and browsers on private computer systems or networks and not just the World-Wide-Web.
A site, i.e. an organization having a computer connected to a network, that wishes to make documents available to network users is called a xe2x80x9cWeb sitexe2x80x9d and must run a xe2x80x9cWeb serverxe2x80x9d program to provide access to the documents. A Web server program is a computer program that allows a computer on the network to make documents available to the rest of the World-Wide-Web or a private web. The documents are often hypertext documents in the HTML language, but may be other types of document objects as well, as well as images, audio and video information. The information that is managed by the Web server includes hypertext documents that are stored on the server or are dynamically generated by scripts on the Web server. Several Web server software packages exist, such as the Conseil Europeen pour la Recherche Nucleaire (CERN, the European Laboratory for Particle Physics) server or the National Center for Supercomputing Applications (NCSA) server. Web servers have been implemented for several different platforms, including the Sun Sparc 11 workstation running the Unix operating system, and personal computers with the Intel Pentium processor running the Microsoft(copyright) MS-DOS operating system and the Microsoft(copyright) Windows(trademark) operating environment.
Web servers also have a standard interface for running external programs, called the Common Gateway Interface (CGI). CGI is described in more detail in How To Set Up and Maintain A Web Site, by Lincoln D. Stein, Addison-Wesley, August 1995. A gateway is a program that handles incoming information requests and returns the appropriate document or generates a document dynamically. For example, a gateway might receive queries, look up the answer in an SQL database, and translate the response into a page of HTML so that the server can send the result to the client. A gateway program may be written in a language such as xe2x80x9cCxe2x80x9d or in a scripting language such as Perl or Tcl or one of the Unix operating system shell languages. The CGI standard specifies how the script or application receives input and parameters, and specifies how any output should be formatted and returned to the server.
A user (typically using a machine other than the machine used by the Web server) that wishes to access documents available on the network at a Web site must run a client program called a xe2x80x9cWeb browser.xe2x80x9d The browser program allows the user to retrieve and display documents from Web servers. Some of the popular Web browser programs are: the Navigator browser from NetScape Communications Corp., of Mountain View, Calif.; the Mosaic browser from the National Center for Supercomputing Applications (NCSA); the WinWeb browser, from Microelectronics and Computer Technology Corp. of Austin, Tex.; and the Internet Explorer, from Microsoft Corporation of Redmond, Wash. Browsers exist for many platforms, including personal computers with the Intel Pentium processor running the Microsoft(copyright) MS-DOS operating system and the Microsoft(copyright) Windows(trademark) environment, and Apple Macintosh personal computers.
The Web server and the Web browser communicate using the Hypertext Transfer Protocol (HTTP) message protocol and the underlying transmission control protocol/internet protocol (TCP/IP) data transport protocol of the Internet. HTTP is described in Hypertext Transfer Protocolxe2x80x94HTTP/1.0, by T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen, Internet Draft Document, Oct. 14, 1995, and is currently in the standardization process. At this writing, the latest version is found in RFC Z068, which is a draft definition of HTTP/1.1. In HTTP, the Web browser establishes a connection to a Web server and sends an HTTP request message to the server. In response to an HTTP request message, the Web server checks for authorization, performs any requested action and returns an HTTP response message containing an HTML document resulting from the requested action, or an error message. The returned HTML document may simply be a file stored on the Web server, or it may be created dynamically using a script called in response to the HTTP request message. For instance, to retrieve a document, a Web browser sends an HTTP request message to the indicated Web server, requesting a document by its URL. The Web server then retrieves the document and returns it in an HTTP response message to the Web browser. If the document has hypertext links, then the user may again select a link to request that a new document be retrieved and displayed. As another example, a user may fill in a form requesting a database search, the Web browser will send an HTTP request message to the Web server including the name of the database to be searched and the search parameters and the URL of the search script. The Web server calls a program or script, passing in the search parameters. The program examines the parameters and attempts to answer the query, perhaps by sending a query to a database interface. When the program receives the results of the query, it constructs an HTML document that is returned to the Web server, which then sends it to the Web browser in an HTTP response message.
Request messages in HTTP contain a xe2x80x9cmethod namexe2x80x9d indicating the type of action to be performed by the server, a URL indicating a target object (either document or script) on the Web server, and other control information. Response messages contain a status line, server information, and possible data content. The Multipurpose Internet Mail Extensions (MIME) are a standardized way for describing the content of messages that are passed over a network. HTTP request and response messages use MIME header lines to indicate the format of the message. MIME is described in more detail in MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, Internet RFC 1341, June 1992.
The request methods defined in the HTTP/1.1 protocol include GET, POST, PUT, HEAD, DELETE, LINK, and UNLINK. PUT, DELETE, LINK and UNLINK are less commonly used. The request methods expected to be defined in the final version of the HTTP/1.1 protocol include GET, POST, PUT, HEAD, DELETE, OPTIONS and TRACE. DELETE, PUT, OPTIONS and TRACE are expected to be less commonly used. All of the methods are described in more detail in the HTTP/1.0 and HTTP/1.1 specifications cited above.
Finally, a device or application using conventional World-Wide-Web technology must have access to a server. Conventional servers are large software packages, which run on relatively large, resource-rich computer systems. These systems are resource-rich in terms of processing speed and power, long-term storage capacity, short-term storage capacity and operating system facilities. Conventional servers take advantage of these resources, for example, in how they store content source documents. For high-speed, convenient access to content, it is conventionally stored in a directory tree of bulky ASCII text files. Therefore, conventional World-Wide-Web technology cannot be used to implement a GUI in a relatively small, inexpensive, resource-poor device or application.
The combination of the Web server and Web browser communicating using an HTTP protocol over a computer network is referred to herein as the World-Wide-Web communications paradigm.
It is therefore an object of the present invention to provide an improved graphical user interface (GUI) for use in connection with remote control, management, configuration, monitoring and diagnosing functions embedded in applications, devices and equipment.
According to one aspect of the invention, there is provided a method for providing a graphical user interface having dynamic elements. The method begins by defining elements of the graphical user interface in at least one text document written in a mark-up language. Next, the method defines including at a location in the document a code tag containing a segment of application source code. The text document is then served to a client which interprets the mark-up language; and when the location is encountered, the client is served a sequence of characters derived from a result of executing a sequence of instructions represented by the segment of application source code. An embodiment of code tags illustrating their use is described in detail, later.
According to another aspect of the invention, there is another method for providing a graphical user interface having dynamic elements. This method also defines elements of the graphical user interface in at least one text document written in a mark-up language. Included in the document is a string identified by prototype tags. The text document is served to a prototyping client which interprets the mark-up language but does not recognize and does not display the prototype tag, but does display the string. An embodiment of prototype tags illustrating their use is described in detail, later.
According to yet another aspect of the invention, there is yet another method for providing a graphical user interface having dynamic elements. Elements of the graphical user interface are defined in at least one text document written in a mark-up language. Included at a location in the document is a code tag containing a segment of application source code. Also included in the document is a string identified by prototype tags. The text document is compiled into a content source, which is subsequently decompiled into a replica of the text document. The replica of the text document is served to a client which interprets the mark-up language; and when the location is encountered in the replica, the client is served a character stream generated by executing the segment of application source code.
Yet another aspect of the invention is a software product recorded on a medium. The software product includes a mark-up language compiler which can compile a mark-up language document into a data structure in a native application programming language, the compiler recognizing one or more code tags which designate included text as a segment of application source code to be saved in a file for compilation by a compiler of the native application programming language.
Another aspect of the invention is a method for providing a graphical user interface having displayed forms for entry of data. The steps of this method include defining elements of the graphical user interface in at least one text document written in a mark-up language; naming in the document a data item requested of a user and used by an application written in a native application programming language; and compiling the text document into a content source including a data structure definition in the native application programming language for the named data item.
Yet another aspect of the invention may be practiced in a computer-based apparatus for developing a graphical user interface for an application, the apparatus including an editor which can manipulate a document written in a mark-up language and a viewer which can display a document written in the mark-up language. The apparatus further includes a markup language compiler which recognizes a code tag containing a source code fragment in a native application source code language, the code tag not otherwise part of the mark-up language, the compiler producing as an output a representation in the native application source code language of the document, including a copy of the source code fragment.
In accordance with another aspect of the invention, there is a method for developing and prototyping graphic user interfaces for an application. The method includes accessing an HTML file, encapsulating portions of said HTML and entering source code therein, producing a source module from said HTML with encapsulated portions, producing source code for a server, and cross compiling and linking said application, said source code module and said server thereby producing executable object code.
The invention, according to another aspect thereof, may be a data structure fixed in a computer readable medium, the data structure for use in a computer system including a client and a server in communication with each other. The data structure includes crosscompiled, stored and linked, HTML files with encapsulated portions containing executable code associated with said application, server code, and application code, wherein said executable code is run when the HTML file is served thereby providing real time dynamic data associated with said application.